home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Aug 90 / MacApp.Tech$ 8⁄31⁄90 / 1862-Multiple Inheritance-Aug90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.0 KB  |  69 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  LOOMIS       to GUITTET1
  2.  
  3. Item    1202215                         29-Aug-90        15:41PDT
  4.  
  5. From:   ALGER                           KPMG Peat Marwick, Jeff Alger,VCA
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Multiple Inheritance
  10.  
  11. While busy hammering away on our book, Foundations of Object Oriented
  12. Programming for the Macintosh, we noticed the on-going MacApp.Tech$ thread on
  13. multiple inheritance.
  14.  
  15. It appears to us that the most interesting part of the discussion is not the
  16. multiple inheritance arguments, but the lack of an agreed upon model of
  17. inheritance itself.  This, in fact, is a problem throughout the literature on
  18. the subject.  One cannot talk about multiple inheritance absent a discussion of
  19. inheritance in general.  To pose a few questions (and a few answers):
  20.  
  21. - Should inheritance be used for simply code reuse (definitely)?
  22.  
  23. - Should inheritance be used for derived types and is-a relationships (by all
  24. means)?
  25.  
  26. - Are there other legitimate uses of inheritance based solely on semantic
  27. modelling - capturing the MEANING of a program, not just its structure
  28. (YES!!!)?
  29.  
  30. - When should each be used?
  31.  
  32. - Is multiple inheritance better than work arounds (yes - for taking advantage
  33. of polymorphism, avoiding parallel derivation hierarchies, and capturing
  34. program semantics in a natural way)?
  35.  
  36. The real problem is that inheritance and sub-typing (or sub-class) are NOT the
  37. same thing.  They are tightly coupled in Object Pascal, but divorced (though
  38. still going out with each other) in C++.
  39.  
  40. Oft-quoted Meyer in fact reinforces our ideas that he is concerned with
  41. building (i.e. languages) and not architecture and modelling (i.e., ANALYSIS
  42. AND DESIGN).  This is the most common perspective from the computer science
  43. community, where OOP is viewed as a language, not a methodology.
  44.  
  45. Other people are more concerned with abstraction hierarchies that mirror the
  46. real world.  This is semantic modelling, not just a nifty implementation
  47. strategy.  Although most current methodologies for OOP development make an
  48. assumption that it is a legitimate basis for semantic modelling, there is
  49. precious little justification for this in the literature, nor are real
  50. differences between the object model and the way people really think properly
  51. accounted for.  Anyone interested in why should run, not walk, to their
  52. neighborhood bookstore for a copy of Women, Fire and Dangerous Things by George
  53. Lakoff and not torment themselves with another OOP project until they have
  54. devoured it.
  55.  
  56. The sifting of all of these concepts: object orientation, inheritance (NOT
  57. implied by objects!), multiple inheritance, semantic modelling, behavioral
  58. modelling, ad nauseum, is a very difficult task.  Too many people are making
  59. too many unstated assumptions about the foundations of OOP and borrowing too
  60. many terms unjustifiably.  This makes serious discussion difficult.
  61.  
  62. Tossing a hand grenade where it will do the most damage,
  63.  
  64. We remain,
  65.  
  66. Neal Goldstein              Jeff Alger
  67. Neal Goldstein Design, Inc.    KPMG•Exis
  68.  
  69.